\section{Introduction}

The \commonlisp{} standard contains many references to environments.
Most of these references concern \emph{lexical} environments at
\emph{compile time}, because they are needed in order to process forms
in non-null lexical environments.  The standard does not specify the
nature of these objects, though in CLtL2 \cite{Steele:1990:CLL:95411}
there is a suggested protocol that is sometimes supplied in existing
\commonlisp{} implementations. 

When it comes to \emph{global environments}, however, the standard is
even more reticent.  In section 3.2.1 (entitled Compiler Terminology)
of the \commonlisp{} \hs{}, the distinction is made between the
\emph{startup environment}, the \emph{compilation environment}, the
\emph{evaluation environment}, and the \emph{runtime environment}.
Excluding the runtime environment, the standard allows for all the
others to be identical.

In a typical \commonlisp{} implementation, these global environments
are not first-class objects, and there is typically only one global
environment available as specifically allowed by the standard.  In some
implementations, part of the environment is contained in other
objects.  For instance, it is common for a symbol object to contain a
\emph{value cell} containing the global value (if any) of the variable
having the name of the symbol and/or a \emph{function cell} containing
the definition of a global function having the name of the symbol.
This kind of representation is even implicitly suggested by the
standard in that it sometimes uses terminology such as \emph{value
  cell} and \emph{function cell}%
\footnote{See for instance the glossary entries for \emph{cell},
  \emph{value cell}, and \emph{function cell} in the
  \hs{}.},  while pointing out that this terminology is ``traditional''.

In this paper, we argue that there are many advantages to making the
global environment a first-class object.  An immediate advantage is
that it is then possible to distinguish between the \emph{startup
  environment}, the \emph{compilation environment} and the
\emph{evaluation environment} so that compile-time evaluations by the
compiler are not visible in the startup-environment.  However, as we
show in this paper, there are many more advantages, such as making it
easier to create a so-called \emph{sandbox} environment, which is
notoriously difficult to do in a typical \commonlisp{}
implementation.  Another significant advantage of first-class global
environments is that it becomes unnecessary to use temporary package
names for bootstrapping a target \commonlisp{} system from a host
\commonlisp{} system.

In order for first-class global environments to be a viable
alternative to the traditional implementation method, they must not
incur any performance penalty, at least not at runtime.  We show an
implementation of first-class global environments that respects this
constraint by supplying \emph{cells} that can be thought of as the
same as the traditional value cells and function cells, except that
they are dislocated so that the are physically located in the
environment object as opposed to being associated with a symbol.

%%  LocalWords:  startup runtime
